進入《驗證與品質保證》階段的第一天，我們將探討一個常被忽視但極其關鍵的主題：「系統驗收準則制定」。
經過前面 17 天的討論，我們已經建立了完整的開發流程：從需求確認、系統設計、技術規劃到持續整合。最後，我們面臨到的一個關鍵問題：
「我們如何確定，我們所打造的系統，真的符合最初的商業期待？」
軟體的「完成」不是由開發者說了算，而是由「驗收標準」說了算。如果說前面的章節是教我們 「如何正確地做事 (Do things right)」 ，那麼驗收準則制定就是確保我們 「做對的事情 (Do the right thing)」 。
還記得我們在 day13 時所討論的 <跨團隊協作設計：技術文件、OpenAPI、共用契約> 這個議題嗎? 在這個主題中我們說過
在核心商業邏輯被初步實現後，我們就可以根據現有資訊進行一場探索業務領域的協作，方式有很多種，像是會議或是工作坊，目標是建立團隊對於業務流程的共同語言與理解。這樣一來就比較能確保
「我們正在打造對的東西 (building the right thing)」，然後在進入「把東西做對 (building the thing right)」時才不會出現南轅北轍的窘境。
雖然說在一開始的共同契約制定中，沒有特別說到是否有測試團隊的參與，但我們在進行系統交付前，仍然必須有一個關於 驗證與品質保證 的進程必須執行完畢 - 就算我們對自己的演奏曲目再有信心，也應該再演出前先確認我們的樂器音準是否失調吧?
後續 4 天(含今天)的內容我們將會一同分享與了解 測試規則的設計方針 => 使用者實際操作盲測 => 前端介面測試 => 後端效能測試 這四個進程，在上一個階段(軟體開發與持續整合)我們是將系統有裡到外的進行生長發展的話，接下來我們將要由皮入肓的不斷去驗證 商業邏輯 是否被成功實踐。
這是一門關於 「承諾」 與 「信任」 的藝術，是確保我們最終交付的產品，真正解決了客戶問題的關鍵。在業界，再厲害的技術，如果做出來的東西不是客戶想要的，那一切都是白費功夫。 這就引出了兩個核心概念的根本區別： 驗證 (Verification) 與確認 (Validation)。
驗證 是在問：「我們是否正確地建構了系統？」（Are we building the system right?）。它關注的是系統是否符合技術規格、設計文件與編碼標準。這是一個向內的審視，確保技術執行的精準度。單元測試、整合測試都屬於此範疇。
確認 則是在問：「我們是否建構了正確的系統？」（Are we building the right system?）。它關注的是系統是否滿足了真實的業務需求與使用者的期望。這是一個向外的審視，確保產品的商業價值與實用性。
接下來，想像成我們正在一起 蓋一棟房子 ，起點從客戶的一個夢想藍圖( 需求確認 )，一直到他滿意地拿著鑰匙住進去( 交付系統 )。
我們可以把整個過程，拆解成四個環環相扣的步驟：
這是一個根本性的心態轉變 (Mindset Shift)。
在客戶簽下合約，說他想要一棟「舒適、安全、現代化的房子」時，這就是一個 需求 (Requirement) 。
但什麼是「舒適」？什麼是「安全」？
我們透過了共同契約有了一個業務的實現邊界認知與情境設定，在這個過程中 UI/UX 也一同參與進來並且產出了一個設計稿，其中包含了 UI 設定與 UX 流程，看起來好像沒什麼問題了，對吧?
過去，我們衡量專案成功與否，常常看的是「我們交付了多少功能？」這就是 功能交付 (Function Delivery) 思維。就像蓋房子，我們對客戶說：「你看，合約上寫的 10 扇窗戶、3 個房間、2 間衛浴，我們都蓋好了，不多不少。」我們的工作就結束了。
但是，客戶真的滿意嗎？
雖然房間數對了，但西曬的房間夏天熱得像烤箱，根本沒法待；雖然窗戶數量對了，但開窗看到的是鄰居的牆壁，毫無景觀可言。
驗證邏輯 (Verification Logic) 就是我們把這些抽象概念，轉化為可被檢驗的思考過程。這是最核心、最抽象，也最重要的一步。
客戶說：「我需要一個安全的門。」
我們的驗證邏輯就要思考：
- 「如果」一個門是安全的，「那麼」它必須滿足以下條件：
- 它要有個無法輕易被撬開的鎖。
- 它的材質必須堅固，不能一撞就破。
- 門框和門本身必須密合，沒有過大的縫隙。
看到這個 「如果...那麼...」(If-Then) 的思考模式了嗎？這就是驗證邏輯。它旨在建立一個因果關係和判斷基礎。我們 不是在寫測試案例，我們是在 定義「什麼才叫做對」。這個邏輯，直接源自於商業需求與風險 - 一個銀行的 APP 的「安全」驗證邏輯跟一個遊戲 APP 的驗證邏輯，絕對天差地遠。
很多專案的失敗，源頭就在這裡。 開發團隊 和 客戶 對「安全」的想像完全不同，直到最後要交屋了才發現，客戶想要的是銀行金庫的門，而我們只給了他一個普通的木門，或者正好相反的用 2012 規格來設計迪士尼入園大門。 驗證邏輯 ，就是在動工前，先把雙方的 「想像」對齊 。雖然 PM 與 UI/UX 夥伴已經應可能的協助我們設定好我們的情境設定與開發邊界，但 價值驗收 (Value Acceptance) 的思維依舊必須在開發與測試議題設定時，不斷的追問自己：
「我們交付的系統，是否真正解決了使用者的問題？」
「我們交付的系統，是否實現了預期的商業邏輯(共同契約)？」
在傳統的開發模式中，「完成」通常被定義為：
開發者：「登入功能做完了！」
測試人員：「好的，我來測試看看有沒有 Bug。」
產品經理：「Bug 修完了嗎？沒有的話就可以上線了。」
這種思維的問題在於，它假設 「沒有技術錯誤」就等於「符合商業需求」。但現實往往是殘酷的：
相較之下，「價值驗收」導向的思維將「完成」重新定義為：
產品經理：「我們需要驗證這個功能是否真的解決了用戶的痛點。」
利害關係人：「讓我親自體驗一下完整的用戶旅程。」
開發團隊：「我們一起確認這個解決方案是否達到了預期的商業目標。」
這種思維轉換的核心，在於將評判標準從 「技術正確性」 升級為 「商業價值(Domain)實現」 。
有了驗證邏輯這個「思考框架」，我們就可以把它具體化，變成一條條清晰、可衡量、無歧義的規則。
這就是 系統驗收準則 (Acceptance Criteria, AC)。
AC 是對一個功能或一個使用者故事 (User Story) 的「通過條件」。它必須是二元的，只有「通過」或「不通過」，沒有模糊空間。一套良好的驗收準則，必須同時扮演著兩個重要角色：
1. 開發指南針 (Development Compass)
2. 交付品質閘門 (Quality Gate)
讓我們延續剛剛的房子例子：
每一條 AC 都非常具體，可以直接被測試。它把「安全的門」這個 抽象概念，變成了工程師可以實現、測試人員可以驗證的 具體規格。
AC 是開發團隊的「開發規格書」，也是測試團隊的 「考試重點」，更是未來 與客戶溝通的「對外契約」 。在敏捷開發 (Agile) 中，AC 更是每個使用者故事不可或缺的一部分。沒有 AC 的功能，就像沒有標示尺寸的設計圖，工人根本無從下手。
常見的撰寫主要有兩種主流格式，每種格式都有其適用的場景。
格式一：規則導向 (Rule-Oriented) — 清單格式
這種格式以一系列清晰的規則清單來定義驗收條件。它非常適合用來描述那些具有明確、非順序性業務規則的使用者故事，或是定義非功能性需求(如性能、安全性)。
這種格式的優點是直觀、易於理解，非常適合用來驗證一組獨立的業務規則。
格式二：情境導向 (Scenario-Oriented) — Given/When/Then 格式
這種格式源於行為驅動開發 (Behavior-Driven Development, BDD)，使用一種名為 Gherkin 的特定語法來描述使用者與系統互動的具體情境 。它對於描述工作流程、使用者操作順序和複雜的互動場景尤為出色。
其核心結構為：假設 ( Given )、當 ( When )、那麼 ( Then) 。
假設 (Given): 描述情境發生前的初始狀態或前提條件。
當 (When): 描述使用者執行的特定動作。
那麼 (Then): 描述在該動作之後，系統應呈現的預期結果。
範例：
使用者：「身為一個購物者，我想要在結帳時使用折扣碼。」
其情境導向的 AC 可能如下：
情境一：套用有效的折扣碼
假設 我的購物車內有商品，且我位於結帳頁面。
當 我在折扣碼欄位輸入 "SAVE10" 並點擊「套用」按鈕。那麼 訂單總金額應減少 10%。
情境二：套用無效的折扣碼
假設 我的購物車內有商品，且我位於結帳頁面。當 我在折扣碼欄位輸入一個無效的折扣碼 "INVALIDCODE" 並點擊「套用」按鈕。那麼 訂單總金額應維持不變。
並且 我應該看到一條錯誤訊息，內容為「此折扣碼無效或已過期」。撰寫優良 AC 的最佳實踐包括：必須清晰簡潔、可測試（具有明確的通過/失敗結果）、並且專注於 「做什麼 (What)」 ，而非 「如何做 (How)」 。同時，定義負面情境（如上例的情境二）與邊界條件，對於確保系統的穩健性至關重要
關鍵概念：驗收準則不是事後的檢查清單，而是事前的設計約束。它們應該在開發開始之前就被明確定義，並在整個開發過程中持續指導決策。
現在我們有了規則 (AC)，接下來就要讓 房子的主人 (End User) 親自來檢查。我們不能只給他一張清單，我們要給他一本 操作手冊，引導他一步步地檢查，這本手冊就是 功能驗收手冊 (UAT Manual)，而整個過程就是 使用者驗收測試 (User Acceptance Testing, UAT) 。
我們先繼續用房屋驗收來進行舉例:
這個手冊把抽象的 AC 變成了使用者在真實世界中的一個個實際行為。
一個好的 UAT 流程，遠比一份完美的 UAT 手冊 重要。很多公司有詳細的手冊，但流程一團亂：
UAT 經常被誤解為「最後的測試階段」，但實際上，它是一個完整的期望管理框架。這個框架的目的，是確保所有參與項目的人員 - 無論是技術團隊、業務團隊還是最終用戶 - 都對系統的能力和限制有一致的理解。 在 UAT 之前，所有的測試都是由技術團隊（開發者、QA 工程師）從技術角度執行的，而 UAT，則是由真正的終端使用者、客戶或業務領域專家，在模擬真實世界的場景中，從業務流程與使用者體驗的角度來進行。
它的目標不是為了尋找程式碼中的微小錯誤 - 儘管這也可能發生 - 而是為了確認整個系統的端到端業務流程是否順暢，是否 真正解決了 最初提出的業務問題。
第一層：商業價值驗證 (Business Value Validation)
一切始於一個想法、一個目標或一個痛點。可能是「我們需要提升客戶的續訂率」，也可能是「目前的訂單處理流程太耗時了」。這些高層次的業務需求，雖然指明了方向，但對於開發團隊來說，卻是無法直接執行的。因此，整個 驗收架構 的第一步，也是最重要的一步，就是將這些 核心商業價值驗證，解構成為具體、可操作的 驗證標準
這一層關注的是系統是否真正解決了商業問題。驗證的重點包括：
實際案例：
原始需求：「提升客服效率」
傳統驗收：「客服系統能正常運作，回應時間 < 2 秒」
價值驗收：「客服人員單日處理案件數量提升 30%，用戶滿意度評分提升至 4.2/5.0」
第二層：使用者體驗驗證 (User Experience Validation)
為了實現這一點，業界普遍採用一種強大的工具，我們稱之為使用者故事 (User Story)。在先前的<使用者的系統操作情境 - User Story 與 Scenario Flow>與<跨團隊協作設計：技術文件、OpenAPI、共用契約>我們都有聊過， User Story 不僅僅是一種文件格式，更是一種思維模式的轉變，它迫使我們從系統的功能視角，轉向 使用者的價值視角 - 這也是 Domain 的實踐之一。
這一層則是關注系統的可用性和用戶旅程的完整性：
實際案例：
功能：「線上購物車」
技術驗收：「添加商品、修改數量、結帳功能正常」
體驗驗收：「首次使用的用戶能在 5 分鐘內完成首次購買，且 95% 的用戶能夠不查看說明文件就完成操作」
第三層：技術品質驗證 (Technical Quality Validation)
這一層關注的是系統的非功能性需求：
當我們奠定了堅實的邏輯基礎後，下一步就是設計一個系統化、可重複的流程，來執行我們的確認工作。這部分將探討如何從宏觀的戰略規劃，到微觀的團隊組建與文件撰寫，來架構整個 UAT 流程。
階段一：驗收準則定義 (Acceptance Criteria Definition)
在這個階段就是我們之前所說的 共同契約 的業務理解與邊界確認，將商業需求轉化為具體、可測試的驗收條件。這個轉化過程絕非閉門造車，而是需要透過訪談、工作坊等形式，與所有關鍵的利害關係人 (Stakeholders) 進行深度協作，包括產品負責人 (Product Owner)、業務領域專家 (Subject Matter Experts, SMEs) 以及最終使用者。
我們需要清晰闡述本次 UAT 的目的，以及它旨在確認的具體業務目標 。例如：「本次 UAT 的目標是確認新的線上結帳流程能夠在 2 分鐘內完成，並支持三種主流支付方式，以提升轉換率 5%。」並且制定 範疇（範圍內與範圍外）(Scope - In & Out)。 範圍內 (In-Scope) 需明確列出本次 UAT 將要測試的功能模組、業務流程、使用者角色等，而同樣重要的是 範圍外 (Out-of-Scope)要明確列出不在本次測試範圍內的項目 。這能有效防止在測試過程中出現範疇蔓延，避免 測試人員測試那些尚未完成或不相關的功能，從而浪費寶貴的時間 。
關鍵活動：
實作工具建議：
階段二：測試環境準備 (Test Environment Preparation)
在這時候，我們需要建立一個能夠真實反映生產環境的測試環境，同時確定測試團隊的成員、所需的軟硬體環境、測試工具，並制定一份包含重要里程碑的詳細時間表。
關鍵考量：
AWS 實作建議：
詳情可看<Dev / Staging / Prod 多環境治理與架構策略: AWS 多環境配置管理與部署策略>
# 使用 Terraform 確保環境一致性
resource "aws_ecs_service" "uat_environment" {
name = "uat-app-service"
cluster = aws_ecs_cluster.uat_cluster.id
task_definition = aws_ecs_task_definition.app.arn
desired_count = 2
# 確保與 Production 使用相同的基礎架構配置
load_balancer {
target_group_arn = aws_lb_target_group.uat_tg.arn
container_name = "app"
container_port = 80
}
}
階段三：驗收測試執行 (Acceptance Test Execution)
這時有一個 UAT 流程治理的核心，也是整個 UAT 計畫中 必須遵守 的管理準則。
進入與退出準則
進入準則 (Entry Criteria) 定義了 UAT 可以開始的前提條件，這些條件必須全部滿足，UAT 流程才能正式啟動 。常見的進入準則包括：
退出準則 (Exit Criteria) 則定義了 UAT 可以結束並視為成功的條件。這些是決定系統是否可以「上線 (Go-live)」的客觀依據。常見的退出準則包括：
進入與退出準則 不僅僅是測試團隊的內部共識，它們是專案管理中極其有力的 談判與期望管理工具 。專案中常見的一個失敗點，是在一個充滿錯誤、不穩定的系統上過早地開始 UAT，這不僅會嚴重打擊測試人員的士氣，也會侵蝕業務方對專案的信心；另一個失敗點則是陷入無休止的 UAT 循環，因為 「完成」的標準 始終在變動。
進入準則 透過建立一個正式的、預先協商好的 「準備好進行 UAT」 的定義，來解決第一個問題，開發團隊清楚地知道他們必須達成的品質目標，而業務團隊也明白，在這些目標達成之前，他們不會被要求投入測試。
退出準則 則透過明確定義 「完成」的標準 ，來解決第二個問題。它將「上線」的決定從一種主觀的感覺（「我覺得系統差不多了」）轉變為一個客觀的檢查清單（「我們是否滿足了所有的退出準則？」）。因此，在 UAT 開始之前，就定義好這些準則並獲得所有利害關係人的簽名同意，是一項至關重要的風險管理活動，它為開發和業務雙方都施加了必要的紀律。
執行策略：
測試記錄範例：
## 驗收測試記錄
**測試場景**: 新用戶註冊與首次購買流程
**測試人員**: 業務代表 Alice, 技術負責人 Bob
**測試時間**: 2025-09-23 14:00-15:30
### 執行結果
✅ 用戶能在 3 分鐘內完成註冊
✅ 註冊後自動導向產品推薦頁面
❌ 首次購買流程中，優惠券選擇功能不夠直觀
⚠️ 結帳頁面載入時間稍長（4.2 秒），但在可接受範圍內
### 發現的問題
1. 優惠券介面需要增加說明文字
2. 結帳頁面需要增加載入進度指示器
### 後續行動
- [ ] UI/UX 團隊修改優惠券介面設計
- [ ] 前端團隊增加載入進度指示器
- [ ] 預計 2 天內完成修改，重新測試
階段四：驗收決策與交付 (Acceptance Decision & Delivery)
最終我們基於測試結果，做出明確的驗收決策：
決策矩陣：
工具和流程固然重要，但 UAT 的成敗最終取決於 「人」 。UAT 的全名是 使用者驗收測試 ，這意味著測試的執行者必須是能夠代表最終使用者的人。
理想的 UAT 測試人員是來自 業務部門 的真實使用者或領域專家 ( SMEs )。他們深刻理解日常工作的流程、痛點和細微之處，這是任何 QA 工程師或開發者都無法完全模擬的。選擇一個能夠代表不同使用者角色的多元化團隊是最佳實踐，對於一個電商系統，測試團隊應至少包含 顧客服務代表 、 訂單處理人員 和 財務人員。
在 UAT 流程中，明確的角色劃分可以避免混亂，確保資訊流暢通。
最後，我們不能假設業務測試員天生就知道 如何進行有效的測試 。在 UAT 開始前，必須對他們進行培訓。培訓內容不僅應包括新系統的功能操作，更重要的是 UAT 流程本身： 如何使用測試管理或缺陷追蹤工具 、 如何撰寫一份清晰的缺陷報告 以及 理解他們的回饋對於產品質量的重要性 。充分的培訓可以顯著提升 UAT 的效率與品質。
UAT 測試結束了，使用者回報了 20 個問題。請問，這棟房子算「通過」還是「不通過」？我們能交屋嗎？
為了讓 UAT 的「退出準則」不僅僅是口號，我們需要一套客觀、可量化的指標來衡量 UAT 的進展與軟體的品質。這些指標將「感覺良好」轉化為「數據證明」，為最終的「上線/不上線」決策提供堅實的依據
這就是為什麼我們需要 品質標準 (Quality Standard) 。我們在 UAT 開始前，就必須和客戶達成共識，定義什麼樣的結果算是「驗收通過」。量化的品質標準 是 UAT 成功的基礎，沒有清晰、可測量的標準，驗收過程就會變成主觀的爭論或是無盡的又修又改迴圈。
通常我們會將問題（Bug/Defect）分類：
可用性品質標準 (Usability Quality Standards)
| 指標類別 | 具體指標 | 目標值 | 測量方法 |
|---|---|---|---|
| 易學性 | 新用戶完成核心任務的時間 | < 5 分鐘 | 實際測試計時 |
| 效率性 | 熟練用戶任務完成時間 | 比舊系統快 40% | A/B 測試比較 |
| 錯誤恢復 | 用戶自主解決問題的比例 | > 80% | 錯誤處理觀察 |
| 滿意度 | 用戶體驗評分 | > 4.0/5.0 | 問卷調查 |
性能品質標準 (Performance Quality Standards)
| 指標類別 | 具體指標 | 目標值 | 測量工具 |
|---|---|---|---|
| 響應時間 | 頁面載入時間 (P95) | < 2 秒 | Lighthouse CI |
| 吞吐量 | 同時在線用戶數支援 | > 1000 | K6 負載測試 |
| 資源使用 | CPU 使用率 (平均) | < 70% | CloudWatch Metrics |
| 可用性 | 系統正常運行時間 | > 99.5% | 服務監控 |
安全品質標準 (Security Quality Standards)
| 指標類別 | 具體指標 | 目標值 | 驗證方法 |
|---|---|---|---|
| 權限控制 | 未授權存取阻擋率 | 100% | 權限測試 |
| 數據保護 | 敏感數據加密覆蓋率 | 100% | 安全掃描 |
| 審計追蹤 | 關鍵操作記錄完整性 | 100% | 日誌檢查 |
| 漏洞評估 | 高危漏洞數量 | 0 | SAST/DAST 掃描 |
以下是 UAT 階段最關鍵的品質衡量指標：
定義: 已執行的測試案例數量佔總計畫測試案例數量的百分比。
公式:
$(已執行測試案例數/總測試案例數)× 100% $
目的: 追蹤 UAT 的整體進度，確保所有規劃的測試都得到覆蓋 。
定義: 已通過的測試案例數量佔已執行測試案例數量的百分比。
公式:
$(已通過測試案例數/已執行測試案例數)×100%$
目的: 這是衡量軟體穩定性和品質最直接的指標。一個持續偏低的通過率是系統不穩定的強烈信號。
定義: 在特定範圍的軟體中發現的已確認缺陷數量。範圍可以是整個專案、一個模組、或以千行程式碼 (KLOC) 為單位。
公式:
$ 總確認缺陷數/軟體規模$
目的: 評估程式碼的內在品質。高缺陷密度通常意味著需要更深入的程式碼審查或重構 。
定義: 在 UAT 階段發現的，但理應在更早的測試階段（如系統測試）就被發現的缺陷，佔 UAT 總發現缺陷數的百分比。
公式:
$(在UAT發現的應早期發現的缺陷數/ UAT 總發現缺陷數)×100%$
目的: 衡量內部 QA 流程的有效性。高洩漏率表明系統測試階段存在漏洞，需要流程改進。
定義: 有至少一個測試案例與之對應的業務需求，佔總業務需求的百分比。
公式:
$(已覆蓋需求的數量/總需求數量)×100%$
目的: 確保沒有任何業務需求被遺漏，目標是達到 100% 覆蓋 。
缺陷修復率 (Defect Resolution Rate):
定義: 已修復並驗證通過的嚴重/高優先級缺陷，佔所有已發現的嚴重/高優先級缺陷的百分比。
目的: 追蹤開發團隊修復關鍵問題的能力和效率，這通常是退出準則的核心指標之一 。
這些指標共同構成了一個 UAT 儀表板 (Dashboard) ，讓專案管理者和利害關係人可以一目了然地掌握 UAT 的健康狀況。例如:
「當測試執行進度達到 100%，測試案例通過率不低於 95%，需求覆蓋率為 100%，且嚴重/高優先級缺陷修復率達到 100% 時，UAT 方可結束。」
品質標準就是一個這樣的承諾：「當本次 UAT 流程結束時，若系統中不存在任何『致命』與『主要』等級的未解決問題，則視為驗收通過。」這是在設定一個 務實的停損點 - 世界上沒有完美的軟體。如果追求 100% 零瑕疵，那專案可能永遠無法上線，品質標準的制定，體現了一家公司的成熟度，它懂得在 「完美」 與 「務實」 之間取得平衡，確保核心價值交付的同時，又能控制時程與成本。
傳統上， 使用者驗收測試（UAT） 被視為 軟體開發生命週期（SDLC） 末端的一個 獨立、手動的驗證階段。這種模式在現代高速迭代的開發環境中已成為瓶頸。典範轉移的核心是將 UAT 從一個守門員的角色，轉變為一個整合在持續整合與持續交付（CI/CD）流程中的持續品質信號。此轉變與敏捷（Agile）及 DevOps 的核心原則——「快速失敗」（Fail Fast）和縮短反饋迴圈——完全契合 。自動化的 UAT 流程能夠在每次程式碼提交後，迅速驗證業務流程的端到端功能，確保新功能不僅在技術上可行，在業務邏輯上也符合使用者預期。
在現代 DevSecOps 框架下，品質的定義已擴展至包含 安全性、 效能 與 可靠性。UAT 不再僅僅是功能驗證，而是從 使用者視角確保整體體驗 是 安全 、 高效 且 穩定 的最後一道防線。自動化的 UAT 流程可以整合安全測試場景，例如驗證身份驗證流程是否符合預期、權限控制是否正確實施，以及應用程式在模擬負載下的反應是否穩定。透過這種方式，UAT 成為一個全面的品質驗證機制，從使用者的角度確認安全性與營運準備度，從而強化了整體的 DevSecOps 策略 。
我們可以將 UAT 流程視為一個由相互關聯的元素（程式碼、基礎設施、測試人員、反饋迴圈）組成的複雜系統 。這種視角促使我們超越單純的測試腳本自動化，去尋找系統中的「槓桿點」（Leverage Points）以實現更深層次的改進。
核心組件架構：
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ 測試規劃管理 │ │ 執行追蹤系統 │ │ 結果分析平台 │
├─────────────────┤ ├─────────────────┤ ├─────────────────┤
│ • 驗收條件定義 │ │ • 測試進度追蹤 │ │ • 品質指標分析 │
│ • 測試場景設計 │ │ • 問題記錄管理 │ │ • 趨勢報告生成 │
│ • 人員角色分配 │ │ • 協作溝通工具 │ │ • 決策支援資訊 │
└─────────────────┘ └─────────────────┘ └─────────────────┘
僅僅將手動測試步驟轉換為自動化腳本，而忽略了諸如測試環境準備緩慢、缺乏高品質測試數據、或反饋分析流程效率低下等系統性問題，往往只是將瓶頸從一個環節轉移到另一個環節。成功的 UAT 數位化策略必須應用 限制理論（Theory of Constraints） ，繪製從概念到已驗證功能的完整 UAT 價值流，識別出主要的限制因素（例如，測試數據生成 、 環境設定 、 反饋分析），並將自動化努力集中於提升該限制因素的效能 。這種系統性的方法所帶來的投資回報遠超過零散的腳本編寫工作，使得最終目標不僅是自動化測試，而是優化整個產生高品質驗證產品的系統。
但並非所有 UAT 場景都適合自動化，手動測試在某些領域依然無法被取代 ，其價值在於：
我們的 UAT 自動化資源應集中在下列 3 個自動化回報率最高(或者說，手動操作成本最高)的 領域特性(Domain trait) ：
1. 基礎設施即程式碼 (IaC) 作為測試環境基石
雖然我們在<Dev / Staging / Prod 多環境治理與架構策略: AWS 多環境配置管理與部署策略>中，大致說過了我們可以怎麼切割出不同使用環境，但為了減少翻頁困擾，我們一同在這邊再次簡單複習一次。
首先，要實現一致且可重複的 UAT 環境，採用基礎設施即程式碼（IaC）是不可或缺的基礎。
AWS CloudFormation：作為 AWS 的原生 IaC 服務，CloudFormation 提供了強大的環境定義與管理能力。其核心功能包括：
HashiCorp Terraform：在多雲或混合雲場景中，Terraform 提供了卓越的靈活性。其特點包括供應商模型（Provider Model）、人類可讀的 HCL 語法以及強大的狀態管理功能，使其成為跨平台基礎設施管理的熱門選擇 。
安全地管理機密：在 IaC 範本中硬式編碼憑證是嚴格禁止的安全漏洞。正確的做法是整合 AWS Secrets Manager。透過在 CloudFormation 範本中使用動態參考（{{resolve:secretsmanager:...}}），可以在部署時安全地注入資料庫密碼等機密資訊。這種方式不僅避免了憑證洩漏的風險，還能利用 Secrets Manager 的自動輪換功能，進一步提升安全性 。
多帳戶策略實現隔離 :
網路與存取控制
# AWS CDK 實作示意範例
export class UATEnvironmentStack extends Stack {
constructor(scope: Construct, id: string, props?: StackProps) {
super(scope, id, props);
// UAT 環境的 VPC 設定
const uatVpc = new Vpc(this, 'UATVpc', {
maxAzs: 2,
enableDnsHostnames: true,
enableDnsSupport: true
});
// UAT 資料庫 (使用 RDS Snapshot 來確保測試資料一致性)
const uatDatabase = new DatabaseInstance(this, 'UATDatabase', {
engine: DatabaseInstanceEngine.postgres({
version: PostgresEngineVersion.VER_13
}),
vpc: uatVpc,
credentials: Credentials.fromGeneratedSecret('uat-db-credentials'),
// 從生產環境的最新 snapshot 建立
snapshotIdentifier: 'prod-db-snapshot-latest'
});
// UAT 應用服務
const uatService = new FargateService(this, 'UATService', {
cluster: new Cluster(this, 'UATCluster', { vpc: uatVpc }),
taskDefinition: this.createTaskDefinition(),
desiredCount: 2
});
}
}
有意義的 UAT 需要真實的數據，然而，直接使用生產數據會帶來嚴重的安全和隱私風險，並可能違反 GDPR 等法規 。
所以我們可以使用 AWS Glue 來淨化生產數據，這個 Glue 任務可以設定為按計畫執行，或作為 CI/CD 流程的一部分隨需觸發，確保 UAT 環境始終擁有最新、最相關的測試數據。他會有主要的 ETL 任務來協主我們快速產生測試資料:
這個過程確保了測試人員能夠使用高擬真度的數據進行測試，而不會洩漏任何敏感資訊 。
# 測試資料準備腳本
class UATDataManager:
def __init__(self):
self.db = boto3.client('rds')
self.s3 = boto3.client('s3')
def prepare_test_data(self):
"""準備 UAT 測試資料"""
# 1. 從生產環境匯出匿名化資料
self.export_anonymized_data()
# 2. 建立測試專用的資料集
self.create_test_specific_data()
# 3. 設定測試用戶帳號
self.setup_test_users()
def reset_test_environment(self):
"""重置測試環境到乾淨狀態"""
# 確保每次 UAT 都從一致的起點開始
snapshot_id = f"uat-reset-{datetime.now().strftime('%Y%m%d')}"
self.db.restore_db_instance_from_db_snapshot(
DBInstanceIdentifier='uat-database',
DBSnapshotIdentifier=snapshot_id
)
2. 自動化測試執行
接下來我們使用 AWS CodePipeline 進行模擬完整的 UAT 工作流程:
就像我們曾經在< CI/CD 全自動化實作 - GitHub Actions × CodePipeline × CodeBuild : 持續整合部署流水線與任務分割管理>說的
除了在單一 Workflow 檔案中分割 Jobs，為了符合企業級的共用標準與可維護性，我們可以將屬於特定領域 (Domain) 或功能的 Jobs 獨立切割成不同的可重用工作流程 (Reusable Workflows)。當有需要時，主流程就可以像函式庫一樣引用並執行這些獨立的 Jobs。
整個流程本身也應作為程式碼，使用 AWS CDK 或 CloudFormation 進行管理，以確保其可重複性和版本控制。以下整理出一些在 CodePipeline 的不同階段整合各種類型的自動化測試，以建立一個縱深防禦的品質保證體系。
// Playwright UAT AutomatedUAT 自動化腳本示意
const { test, expect } = require("@playwright/test");
test.describe("UAT: 核心用戶旅程", () => {
test("新用戶註冊到首次購買完整流程", async ({ page }) => {
// 第一步：註冊新用戶
await page.goto("/register");
await page.fill('[data-testid="email"]', "uat-user@example.com");
await page.fill('[data-testid="password"]', "TestPassword123");
await page.click('[data-testid="register-button"]');
// 驗收條件：註冊成功後應導向歡迎頁面
await expect(page).toHaveURL("/welcome");
await expect(page.locator("h1")).toContainText("歡迎加入");
// 第二步：瀏覽產品並加入購物車
await page.goto("/products");
await page.click('[data-testid="product-1"]');
await page.click('[data-testid="add-to-cart"]');
// 驗收條件：購物車圖示應顯示數量
const cartCount = await page
.locator('[data-testid="cart-count"]')
.textContent();
expect(cartCount).toBe("1");
// 第三步：完成結帳流程
await page.click('[data-testid="cart-icon"]');
await page.click('[data-testid="checkout-button"]');
// 驗收條件：整個流程應在 5 分鐘內完成
// (透過 test.setTimeout() 設定)
});
});
同時我們也可以使用 AWS Device Farm 進行跨瀏覽器與跨裝置驗證。AWS Device Farm 允許執行自動化驗收測試（如 Appium、Selenium）於大量真實的行動裝置和桌面瀏覽器上。這至關重要，因為它驗證的是在真實世界條件下的使用者體驗，而非模擬器所能完全複製的環境，從而發現特定裝置或瀏覽器上的相容性問題 。
這種方法論的精髓在於，UAT 流程不應被視為生產流程的簡化版或次級版本。相反，它應該是生產發布流程在機制和過程上的「同卵雙胞胎」。它應使用相同的部署策略（如 CodeDeploy 的藍/綠部署）、相同的安全檢查（SAST、DAST、容器掃描）以及相同的產出物晉升邏輯。如此一來，在 UAT 階段「驗收」的，不僅僅是應用程式的程式碼，更是整個發布流程本身。
這種方法極大地降低了最終生產部署的風險，因為部署的機制和流程已經在一個擬真的環境中得到了徹底的測試和驗證。
在<開發者體驗（DX）優化：內部工具與排錯設計>中的 <為「排錯」而設計的系統思維> 我們有提到過，一個及時的 可觀測性 (Observability) 與 可操作的錯誤訊息 (Actionable Error Messages) 對於系統的 「被動救火」 和 「主動預防」 有多麼重要。
同理，一個自動化的 UAT 流程所產生大量數據，不僅僅是為了被動地進行故障排除，它實際上是一種主動的 積極風險管理形式 ，我們可以在效能衰退或潛在的可擴展性瓶頸成為生產事故之前就識別它們，並觸發 立即失敗 來讓開發得以在正式上線前進行調整。
為了實現達成 及時救火與預防火災 ，接下來我們將聊聊如何捕獲、分析這些數據，並基於分析結果採取行動，從而建立一個持續改進的系統。
透過 Amazon CloudWatch 與 AWS X-Ray 對 UAT 環境中的效能趨勢進行分析 ，我們可以在效能衰退或潛在的可擴展性瓶頸成為生產事故之前就識別它們。因此，監控 UAT 不僅是為了測試當前的建置版本，更是為了收集關於下一個生產版本的營運健康狀況情報。這些數據可以為 **「發布(To Be)/不發布(Not To Be)」**的決策提供依據，並預防與效能相關的生產中斷。
# CloudWatch 自定義指標示意
import boto3
from datetime import datetime
cloudwatch = boto3.client('cloudwatch')
def record_uat_metrics(test_session_id, metrics):
"""記錄 UAT 過程中的關鍵指標"""
cloudwatch.put_metric_data(
Namespace='UAT/UserExperience',
MetricData=[
{
'MetricName': 'TaskCompletionTime',
'Dimensions': [
{
'Name': 'TestSession',
'Value': test_session_id
},
{
'Name': 'TaskType',
'Value': metrics['task_type']
}
],
'Value': metrics['completion_time_seconds'],
'Unit': 'Seconds',
'Timestamp': datetime.utcnow()
},
{
'MetricName': 'UserSatisfactionScore',
'Dimensions': [
{
'Name': 'TestSession',
'Value': test_session_id
}
],
'Value': metrics['satisfaction_score'],
'Unit': 'Count',
'Timestamp': datetime.utcnow()
}
]
)
最終，蒐集完數據的後，一個有效的 UAT 儀表板應將關鍵指標資料進行分類視覺化，以便不同角色的人員能快速獲取所需資訊：
到目前為止，我們已經系統性地解構了驗收的完整架構。然而，我們還需要理解這個架構在不同的開發哲學下是如何演變的。我們以常見的 傳統瀑布式 (Waterfall) 與 敏捷式 (Agile) 開發方法的對比。
瀑布式開發中的 UAT:
需求分析 => 設計 => 開發 => 測試，環環相扣，一個階段完全結束後，下一個階段才能開始。在這種模式下，UAT 是整個開發週期的最後一個獨立階段。它是一次性的、大規模的、高風險的「大爆炸」式驗收。使用者在專案啟動數月甚至數年後，才第一次接觸到完整的系統。敏捷式開發中的 UAT:
衝刺 (Sprint) ，每個衝刺（通常為 2-4 週）都會產出一個可交付的、有潛在價值的軟體增量。在敏捷哲學中，UAT 不再是一個遙遠的最終階段，而是一項持續性的活動，它在每一個衝刺結束時都會發生。雖然兩者在具體操作上（如撰寫測試案例、管理缺陷）可能使用相似的工具和技術，但其背後的哲學卻有著天壤之別。敏捷 UAT 透過 快速的回饋循環 ，極大地降低了專案風險。團隊不再需要等到專案結束才發現方向性錯誤，而是在每個衝刺結束時就能得到使用者的確認與校準。這使得產品能夠與不斷變化的業務需求和使用者期望保持同步，展現出遠超瀑布模型的 適應性 與 靈活性 。
更深層次地看，這種模式的轉變，根本性地重塑了使用者在開發過程中的角色。在瀑布模型中，使用者在專案結束時，像一位法官，對數月的工作成果下達最終判決。這種關係充滿了壓力，甚至可能變得對立。
而在敏捷模型中，使用者則是一位合作夥伴。他們在每個衝刺結束時，對一小部分正在進行中的工作 提供回饋。這種頻繁、低風險的互動培養了協作文化。使用者不再是產品的被動接受者，而是成為了主動的共同創造者。他們不僅僅是在確認需求，更是在每一個衝刺中幫助團隊打磨和精煉需求。
因此，從瀑布式 UAT 到敏捷式 UAT 的演進，不僅僅是流程的改變，更是一場文化變革。它重新定義了軟體建造者與軟體使用者之間的關係，從而帶來了更高的使用者滿意度、更快的價值交付和更成功的產品。這，就是現代軟體驗收架構的精髓。希望今天的課程能為你未來的職業生涯，奠定堅實的基礎。
最後，我們要討論如何在團隊中建立一個持續改進的驗收文化。這種文化的核心，是將「驗收」從一個被動的檢查點，轉變為一個主動的學習與改進機會。
1. 個人層次：培養品質意識
2. 團隊層次：建立協作機制
3. 組織層次：制度化支持
驗收過程的復盤機制：
## UAT 復盤會議模板
### 會議資訊
- **項目名稱**:
- **驗收週期**:
- **參與人員**:
### 成功經驗
1. 哪些驗收條件設計得特別好？
2. 哪些流程環節運作順暢？
3. 哪些工具或方法特別有效？
### 改進機會
1. 哪些驗收條件不夠明確？
2. 哪些流程環節造成了延誤？
3. 哪些問題重複出現？
### 具體行動計劃
- [ ] 短期改進 (2 週內)
- [ ] 中期優化 (1 個月內)
- [ ] 長期投資 (3 個月內)
### 經驗萃取
- **最佳實踐記錄**:
- **風險預警清單**:
- **工具改進建議**:
最終，成功的 UAT 流程應該能夠回答三個關鍵問題：
當我們的驗收流程能夠系統性地回答這三個問題時，我們就不僅僅是在「測試軟體」，而是在「驗證價值」。這樣的驗收過程，才能真正確保我們所建構的系統，不只是技術上的成功，更是商業上的成功。
一個健全的驗收架構，其成功並非取決於測試階段的努力，而是取決於從需求分析到驗收標準制定的每一步的精確與嚴謹。我們將一同解構這個從抽象到具體、從邏輯到實踐的完整過程。
更進一步地，UAT 不僅是一個技術流程，它在本質上也是一個建立信任的機制。當開發團隊將產品交付給業務方進行測試時，這不僅僅是品質的檢驗，更是雙方對「需求是否被正確理解並實現」的共同確認。UAT 的流程，特別是最終的「簽核 (Sign-off)」環節，創造了一種正式的協議與共同的責任感。這意味著，一次失敗的 UAT 不僅是技術上的挫敗，更是溝通與共識的瓦解。反之，一次成功的 UAT 不僅僅是品質的通過，更是業務與技術團隊之間合作夥伴關係的正式認可，它為產品的未來奠定了堅實的信任基礎，並有效避免了日後關於「交付成果是否符合需求精神」的爭議。
最終，將 UAT 流程數位化和自動化是一項策略性投資，其回報是更快的交付速度、更高的產品質量、更強的市場競爭力以及更具創新能力的開發團隊。這不僅是建構軟體的方式，更是建構未來品質保證體系的基石。
關鍵要點：
- 驗收準則制定：將模糊的商業需求轉化為具體、可驗證的標準
- UAT 流程設計：建立系統性的利害關係人期望管理框架
- 品質標準體系：制定量化的、可測量的品質指標
- 數位化自動化：利用現代工具提升 UAT 流程的效率與可靠性
- 持續改進文化：將驗收過程視為學習與改進的機會
從「功能交付」到「價值驗收」的轉換，是現代軟體開發成熟度的重要標誌。
iThome鐵人賽
看影片追技術